Kubernetes(k8s)容器编排Pod介绍和使用 |
您所在的位置：网站首页 › 容器node pod › Kubernetes(k8s)容器编排Pod介绍和使用 |
Kubernetes(k8s)容器编排Pod介绍和使用
|
目录
1 Pod 特点1.1 网络1.2 存储
2 使用方式2.1 自主式Pod2.2 控制器管理的Pod
3 自主运行Pod3.1 创建资源清单3.1.1 参数描述
3.2 创建Pod3.3 Pod操作3.3.1 查看Pod列表3.3.2 查看描述信息3.3.3 访问pod3.3.4 删除Pod
4 控制器运行Pod4.1 创建资源清单4.2 参数描述4.2.1 Replicas4.2.2 Selector4.2.3 Pod Template
4.3 创建Pod4.4 Pod操作4.4.1 删除Pod
5 镜像拉取策略5.1 always5.1.1 修改资源清单5.1.2 生效配置5.1.3 查看创建过程
5.2 IfNotPresent5.2.1 修改资源清单5.2.2 生效配置5.2.3 查看创建过程
6 Pod生命周期6.1 各个阶段6.2 Pod重启策略6.3 Pod状态转换6.4 生命周期行为6.4.1 初始化容器6.4.2 容器探测
1 Pod 特点
Pod是kubernetes中你可以创建和部署的最小也是最简的单位，一个Pod代表着集群中运行的一个进程。 Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项，Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。Pod有两个必须知道的特点 1.1 网络 每一个Pod都会被指派一个唯一的Ip地址，在Pod中的每一个容器共享网络命名空间，包括Ip地址和网络端口，在同一个Pod中的容器可以同locahost进行互相通信，当Pod中的容器需要与Pod外的实体进行通信时，则需要通过端口等共享的网络资源。 1.2 存储 Pod能够配置共享存储卷，在Pod中所有的容器能够访问共享存储卷，允许这些容器共享数据，存储卷也允许在一个Pod持久化数据，以防止其中的容器需要被重启。 2 使用方式 2.1 自主式Pod 这种Pod本身是不能自我修复的，当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kuberentes调度到集群的Node上，直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上，Pod不会自愈。 如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除，同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。 2.2 控制器管理的Pod Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例，Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。 例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的 3 自主运行Pod 3.1 创建资源清单通过yaml文件或者json描述Pod和其内容器的运行环境和期望状态，例如一个最简单的运行nginx应用的pod，定义如下 vi nginx-pod.yml apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx:1.12 ports: - containerPort: 80 3.1.1 参数描述下面简要分析一下上面的Pod定义文件： apiVersion： 使用哪个版本的Kubernetes API来创建此对象kind：要创建的对象类型，例如Pod，Deployment等metadata：用于唯一区分对象的元数据，包括：name，UID和namespacelabels：是一个个的key/value对，定义这样的label到Pod后，其他控制器对象可以通过这样的label来定位到此Pod，从而对Pod进行管理。（参见Deployment等控制器对象）spec： 其它描述信息，包含Pod中运行的容器，容器中运行的应用等等。不同类型的对象拥有不同的spec定义。详情参见API文档 3.2 创建Pod使用kubectl创建pod kubectl apply -f nginx-pod.yml
可以通过增加 -o wide查看详细信息 kubectl get pods -o wide
可以通过describe查看pod的详细信息 kubectl describe pod nginx
可以通过k8s创建的虚拟IP进行访问，可以在k8s的任何一个节点访问 curl 10.244.1.10
可以使用delete删除Pod，删除后不能进行恢复 kubectl delete pod nginx
Pod本身不具备容错性，这意味着如果Pod运行的Node宕机了，那么该Pod无法恢复，因此推荐使用Deployment等控制器来创建Pod并管理。 4.1 创建资源清单通过yaml文件或者json描述Pod和其内容器的运行环境和期望状态，例如一个最简单的运行nginx应用的pod，定义如下 vi nginx-pod.yml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.12 ports: - containerPort: 80 4.2 参数描述下面简要分析一下上面的Pod定义文件： 4.2.1 Replicas副本数量 spec.replicas 是可以选字段，指定期望的pod数量，默认是1。 4.2.2 Selector标签选择器 .spec.selector是可选字段，用来指定 label selector ，圈定Deployment管理的pod范围。如果被指定， .spec.selector 必须匹配 .spec.template.metadata.labels，否则它将被API拒绝。如果 .spec.selector 没有被指定， .spec.selector.matchLabels 默认是.spec.template.metadata.labels。 在Pod的template跟.spec.template不同或者数量超过了.spec.replicas规定的数量的情况下，Deployment会杀掉label跟selector不同的Pod。 4.2.3 Pod TemplatePod模板，.spec.template 是 .spec中唯一要求的字段。 .spec.template 是 pod template，它跟 Pod有一模一样的schema，除了它是嵌套的并且不需要apiVersion 和 kind字段。 另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label（不要跟其他controller重复了，参考selector）和适当的重启策略。 .spec.template.spec.restartPolicy 可以设置为 Always , 如果不指定的话这就是默认配置。 4.3 创建Pod kubectl apply -f nginx-pod.yml kubectl get pods -o wide创建后发现，有两个nginx的pod在运行，符合我们的预期
这里可以尝试删除Pod kubectl delete pod nginx-deployment-f77774fc5-cgs82 # 查看Pod详情 kubectl get pods -o wide删除Pod后发现重新新建了一个Pod，这是因为有控制器发现少了一个Pod就会进行重新拉起来一个
pod的镜像拉取策略分为三种： always（总是从官方下载镜像）never（从不下载镜像）ifnotpresent（如果本地没有镜像就从官方下载镜像）。Kubernetes集群默认使用IfNotPresent策略 5.1 always不管是否存在本地镜像，总是从远程仓库下载 5.1.1 修改资源清单我们可以通过修改配置清单来配置不同的策略 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.12 imagePullPolicy: Always ports: - containerPort: 80 5.1.2 生效配置 kubectl apply -f nginx-pod.yml
可以清楚的看到重新下载而没有使用本地镜像
Kubernetes集群的默认策略，如果有本地镜像就使用，没有则从远程仓库下载 5.2.1 修改资源清单我们可以通过修改配置清单来配置不同的策略 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.12 imagePullPolicy: IfNotPresent ports: - containerPort: 80 5.2.2 生效配置 kubectl apply -f nginx-pod.yml
可以清楚的看到没有重新下载镜像而是使用本地的镜像。
POD中明确规定了如下几个阶段 状态值说明挂起（Pending）Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建，等待时间包括调度 Pod 的时间和通过网络下载镜像的时间。运行中（Running）该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。成功（Succeeded）Pod 中的所有容器都被成功终止，并且不会再重启。失败（Failed）Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。未知（Unknown）因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。 实际上还有一中状态Terminating，在代码和文档中都没有说明，但却是存在。这种情况出现杂无法获取所在主机的资源情况，一直在尝试建立连接。 6.2 Pod重启策略在Pod中的容器可能会由于异常等原因导致其终止退出，Kubernetes提供了重启策略以重启容器。 Pod通过`restartPolicy`字段指定重启策略，重启策略类型为：Always、OnFailure 和 Never，默认为 Always。 重启策略对同一个Pod的所有容器起作用，容器的重启由Node上的kubelet执行。Pod支持三种重启策略，在配置文件中通过`restartPolicy`字段设置重启策略： 重启策略说明Always当容器失效时，由kubelet自动重启该容器OnFailure当容器终止运行且退出码不为0时，由kubelet自动重启该容器Never不论容器运行状态如何，kubelet都不会重启该容器注意：这里的重启是指在Pod的宿主Node上进行本地重启，而不是调度到其它Node上。 6.3 Pod状态转换 Pod的容器数Pod当前状态发生的事件Pod结果状态RestartPolicy=AlwaysRestartPolicy=OnFailureRestartPolicy=Never包含一个容器Running容器成功退出RunningSucceededSucceeded包含一个容器Running容器失败退出RunningRunningFailure包含两个容器Running1个容器失败退出RunningRunningRunning包含两个容器Running容器被OOM杀掉RunningRunningFailure 6.4 生命周期行为 6.4.1 初始化容器初始化容器（init container）即应用程序的主容器启动之前要运行的容器，常用于为主容器执行一些预置操作，它们具有两种典型特征。 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成。（注意：如果pod的spec.restartPolicy字段值为“Never”，那么运行失败的初始化容器不会被重启。）每个初始化容器都必须按定义的顺序串行运行。 6.4.2 容器探测容器探测（container probe）是Pod对象生命周期中的一项重要的日常任务，它是kubelet对容器周期性执行的健康状态诊断，诊断操作由容器的处理器（handler）进行定义，Kubernetes支持三种处理器用于Pod探测： ExecAction：在容器内执行指定命令，并根据其返回的状态码进行诊断的操作称为Exec探测，状态码为0表示成功，否则即为不健康状态。TCPSocketAction：通过与容器的某TCP端口尝试建立连接进行诊断，端口能够成功打开即为正常，否则为不健康状态。HTTPGetAction：通过向容器IP地址的某指定端口的指定path发起HTTP GET请求进行诊断，响应码为2xx或3xx时即为成功，否则为失败。任何一种探测方式都可能存在三种结果：“Success”（成功）、“Failure”（失败）、“Unknown”（未知），只有success表示成功通过检测。 |
【本文地址】
今日新闻 |
推荐新闻 |